Enterprises often maintain various types of documents that are stored in different places for different purposes. In many cases, such documents are created and stored according to a variety of different software applications and storage systems. For example, documents may be generated using word processing applications, spreadsheet applications, presentation applications, note applications, graphic design applications, photographic applications, and the like. Generated documents may be stored via a variety of storage systems, including one or more content servers used for storing documents of various types, servers for storing documents as attachments to electronic mail items (e-mail), storage systems for storing documents as attachments to meetings, customer relationship management (CRM) systems for storing documents as attachments to leads or customer data, general purpose document stores for storing documents for routine use, and/or specialized document stores (e.g., Documentum® from Documentum, Inc.) for storing documents for specific, highly regulated needs.
Accessing and working with these various types of documents often requires that the appropriate software for each document type be available to users. The typical enterprise scenario envisions that each person who needs to access or work with a document will have the appropriate software locally installed on the computing device they routinely use. Where everyone has access to the same set and versions of applications, this is a workable approach. However, in many situations, where a number of users may only use a given software application on an infrequent basis the given software application may not be loaded on the users' computing devices by the enterprise. One approach to remedy such problems has been to convert documents into a “published” format that is readily viewable but not readily editable. Another approach to providing access to various document types without the need for local installations of the necessary software packages has been to provide viewing and editing functionality innately within a content server or to provide for direct (i.e., hard coded) integration between a content server and a dedicated system for viewing and editing supported documents; however enterprises are often discouraged from integrating such functionality with their content servers for fear that such integration of additional functionality may reduce processing capacity and capability of the likely mission-critical uses, increase downtime, and/or complicate the management of their content servers. Further, the resources invested in a dedicated system (e.g., the time, effort, and expense associated development, procurement, and deployment) are unlikely to be transferable to another platform.
It is with respect to these and other considerations that the present invention has been made.